Cream of the Crop 26

home *** CD-ROM | disk | FTP | other *** search

/ Cream of the Crop 26 / Cream of the Crop 26.iso / bbs / tdk_v136.zip / DOORKIT.DOC < prev next >

Wrap

Text File | 1997-08-14 | 48KB | 890 lines

╔═══════════════════════════════════════════════════════════════════════════╗ ║ FIRST THINGS FIRST - READ THE FILE WARNING.TXT BEFORE PROCEEDING! ║ ╚═══════════════════════════════════════════════════════════════════════════╝ ┌╦══╦┐ ┌╦══╦┐ ┌╦═══╦┐ │╠══╩╗┐│╠══╩╗┐└╩═══╦┐ └╩═══╩┘└╩═══╩┘└╩═══╩┘ ┌╦ ╦┐┌═╤╦╤═┐┌═╤╦╤═┐┌╔ ┌═╤╦╤═┐┌═╤╦╤═┐┌╔═══╦┐┌╔═══╦┐┌════╦┐ │║ ║│ │║│ │║│ │║ │║│ │║│ │╬══ │╬══ ┌─╔═╝─┘ └╩═══╩┘ ╧╩╧ └═╧╩╧═┘└╩═══╩┘└═╧╩╧═┘ ╧╩╧ └╩═══╩┘└╩═══╩┘└╚════┘ ┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐┌═╤╦╤═┐┌╦ ╦┐┌╦═══╦┐┌╦═══╦┐┌╔═══╦┐ └╩═══╦┐│║ ║││╬══ │║│ │║ ╦ ║│├╬═══╬┤│╠══╦╩┘│╬══ └╩═══╩┘└╩═══╩┘└╩ ╧╩╧ └╩═╩═╩┘└╩ ╩┘└╩ ╚═┘└╩═══╩┘ <tm> A Subsidary Of LA-Soft ─────────────────────────────────────────────────────────────────────────────── ▀▀▀▀▀▀▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀ ▀▀▀▀▀ The DoorKit! ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀ ▀▀▀▀▀▀ ▀▀ ▀▀ The BBS Door Development Kit By The People - For The People! ─────────────────────────────────────────────────────────────────────────────── The ANSI/ASCII/RIP/MAX DoorKit v1.36 No Copyright Notices Expressed Or Implied Compiled By Larry L. Athey From Numerous Sources ─────────────────────────────────────────────────────────────────────────────── The Contributors: ───────────────── This is a list of people who contributed to the cause of beta testing the MAX Graphics related programs and the TDK door development kit. Although there were more people who applied to be beta testers, most of these beta sites never posted anything in the support echo, so I don't consider them to have made any contribution to the cause. But, these people stood by me and my efforts without a single sour word, and never threw in the towel.. Many people apply to be a beta tester for new programs and never think of the qwerks involved in testing untested software. So they quickly give up and avoid beta testing like the plague. Beta testing requires a person to do nearly as much work (if not actually more) as the programmer themself. Programs can't evolve without testers actually running the program and at least trying to make it work even with the bugs in it. True beta testers don't seem to know the meaning of the phrase "I give up", and that's what makes being a program author worth while. I couldn't give a damn if I get one more program registration in my life, so long as there are dedicated common sense thinking people like this standing by you, it's worth while! Let's here it for the people that refused to say "I give up"! Name: BBS: Phone: ─────────────────────────────────────────────────────────────────────────── Brad Larned (1:205/400) The Fresno Online BBS 209-276-3657 Sean Price (1:205/46) Sanctuary From The Law BBS 619-377-3611 Chris Martin (1:219/308) The Mars Station BBS 760-254-3012 Bob Wingender (1:284/11) The Oak Tree BBS 417-581-0868 Chet Rhodes (1:151/124) Hawkmoon's Realm 919-556-8363 Larry Thrasher (1:3612/650) The Night Thrasher BBS 904-937-9144 Thomas Wells (1:3621/1) Renegade's Hideout 615-326-5597 Timothy Barney (1:2622/3) The Gravel Pit 814-942-1552 Cliff Williams (1:112/124) The City Of Thought 904-645-8850 Jon Parise (1:2606/421) Infinite Twilight 908-637-8243 Arthur Stark (1:395/670) Top's Diamond Mine 254-542-8783 Ronald Schlegel (1:110/1065) Dynasty BBS 937-258-1030 David Raasch (1:280/285) Let It Shine Online! 816-461-2290 ─────────────────────────────────────────────────────────────────────────── NOTE: These names appear in no particular order, they are only listed here as the names appear in my MAX Graphics area message base... ─────────────────────────────────────────────────────────────────────────────── NOTE: The DoorKit! requires you to have Turbo Pascal 7.0 or Borland Pascal 7.0 With Objects. Certain compiler directives in these units are not compatible with Turbo Pascal 6.0....If you have Turbo Pascal 6.0 you will have to make a number of modifications to this kit. Sorry, but since I don't use TP6.0, I cannot assist you with any modifications. ─────────────────────────────────────────────────────────────────────────────── Welcome to The DoorKit! ─────────────────────── This is a compilation of various procedures and functions by various authors structured in such a way that I believe makes one of the most powerful BBS door development kits available. The reason for me making this kit is because out of all the door development kits out there I've tried (with source code) they all fall short in one way or another. So what I have done is take all of the the best features of numerous door kits, various source code samples from SWAG, plus procedures I have written myself, and compiled one big door development kit... If you are concerned with the legality of the methods used to develop this kit, let's just say (for the sake of legal matters) that this kit is really a "Parody" on other people's kits. Really, it's a parody.....I just have a crappy sense of humor when it comes to programming. Parodies are legal and cannot go hand in hand with plagiarism. Just ask Weird Al Yankovich... :) If you are still concerned at this point, just look at it like this: Every major door development kit out there does the same thing, the difference is I'm admitting to the use of other people's code whereas they are not. Still the code used in this kit has been completely modified to make it work hand in hand with the rest of the kit, so none of these derivatives are any way comparable to their original sources. Every part of TDK is 100% legal and in no way violates any copyright laws... Do with this kit what you will....All I ask is if you find a better way of doing something (which you will), please send me a copy of what you did so that I can update future versions of this kit. Plus it will help me learn more about the way other people work. My code bores me, I like looking at other people's code to learn new tricks. I will also add your name to the list shown below so you are given full credit for your work... ─────────────────────────────────────────────────────────────────────────────── Basic Features: ─────────────── -Autodetects the caller's graphics rather than relying on drop file info. -Supports ANSI/AVATAR/TTY/RIP/MAX graphics. -Supports DOOR.SYS, DORINFOx.DEF, and MX_USER.DAT drop files. -Full error trapping and logging of expected & unexpected errors. -Full monitoring of carrier dropping and user inactivity time-outs. -DOS, DesqView, Windows, and OS/2, multi-tasker friendly. -Built in highly optimized Pascal 'EXEC' replacement. -Painless, almost automatic overlay implementation. -Overlays will load into XMS or EMS, which ever is available. -Only leaves a 1.2K footprint in memory when swapped out. -Automatic swapping to EMS -> XMS -> Disk. -Supports Fossil, UART, and DigiBoard communications routines. -Full support for non-standard port and IRQ settings. -All door serial I/O settings are fully configurable. -Program startup/initialization streamlined into one InitDoorKit command. -Automatic handling of all program exit processes. -Uses typed control files rather than text based INI files. -Includes a freeware control file editor to distribute with your doors. -Easily definable sysop "F-Keys", no Far Calls needed for these functions. -Easily definable command line parameters. -Full support for local and remote Cursor, Home, End, and Delete keys. -Built in split screen and line by line chat modes with word wrapping. -Numerous cosmetic procedures already written into the package. -Numerous string handling procedures already written into the package. -Numerous file handling procedures already written into the package. -Built in questionnaire/script language. -Built in online MAX/ANSI/ASCII text file reader procedure. -Supports inline color tokens for coloring text files. -Library of global system variable tokens for use in screen/text files. -Includes procedures for full activity and error logging. ─────────────────────────────────────────────────────────────────────────────── What's New? ─────────── -Majorly reduced TDK's memory requirements by eliminating the need for the UltraBGI graphics kit. -Removed all BGI graphics code and replaced it with an add on kit that allows you to write MAX doors in full local SVGA mode. -Removed the virtual screen procedures since they weren't really doing anything noticable or worthwhile (other than eating up extra memory). -Removed quite a few redundant procedures from DOORKIT1.PAS such as the sWriteN, sWritelnN, sWritelnC. No need for these procedures since you can achieve the same results using other procedures in TDK. -Enhanced the activity logging header so it is more concise and easier to read the initial start up data. -Hid the word VIRUS.COM in the DOORKIT1.PAS / PROCEDURE FakeVirus; because a couple pinheads that had way too much time on their hands posted these messages in the LoseNet LoserGroups (ie: UseNet NewsGroups) saying that all BBS Utiliteez Software programs and all TDK doors actually contained a virus in them by that file name. See the file WARNING.TXT for more info. -Fixed numerous bugs in the time slicing related procedures. -Fixed numerous cursor control bugs in the input prompt functions. -Fixed numerous bugs in both ANSI and ASCII chat procedures. -Fixed numerous bugs in the MAX command processing unit. -God only knows what else, it's too hard to keep track...<G>... ─────────────────────────────────────────────────────────────────────────────── Technical Information: ────────────────────── Sorry, this isn't going to be very extensive. The units included in this package are commented pretty well, so there won't be a whole hell of a lot documentation. Sorry about that, but if somebody else out there wants to write complete documentation for it.....Have at it! I'm sure others will probably thank you for it.....I really don't see the lack of documentation being a problem since there has been this world-wide campaign initiated to abolish the reading of documentation anyway... ;) If you are really a hound for more information, just read all the other *.DOC files contained in this archive. Since I am mainly concerned with writing MAX Graphics programs, you will find the MAX*.DOC files to be a lot more concise than this document... The example doors ANSIDOOR.PAS and MAXDOOR.PAS both demonstrate the basics of writing doors with TDK and are both fully commented. Experimentation is the mother of invention, so the best thing to do is just start tinkering with things and see what they do. The procedure/function headers in all of the units are commented as well, so even a newbie Pascal programmer should be able to understand what everything does... Door Initialization: ──────────────────── The DoorKit uses binary, or "Typed" files for storing the configuration for each node. The naming convention for these "Control Files" is NODE###.CTL with the ### representing the current node number. I have included a little utility for creating/editing these control files. You may package this in your doors, or you may write your own configuration routines to handle it. The program MAKECTL.EXE is the control file editor. You simply execute it with the node number on the command line to tell the program which node you wish to create or edit the control file for. You may also wish to write a procedure to read text based control files. I don't like text files because they just slow down a program. A typed file is just a one shot open, read, and close. Whereas text files always require you to read a line, translate it into data the door can use, and repeat the process until you have all of your critical variables set. (Can we say: Sloooooowwwww?) Sorry, the source code for MAKECTL.EXE is not available since it uses commercial development libraries. You can just as easily create a CTL file editor with procedures in TDK itself or any other development kit of your choice... Windows CTL File Editors: ───────────────────────── There are two Windows versions of the CTL file editor available which were written by Brad Larned of FzSoft. There are both 16 and 32 bit versions and both can be Freq'ed or downloaded from the USA MAX Graphics HQ-BBS. Below are the file names for each version: WTDK1610.RAR - 16 bit Windows TDK CTL file editor. WTDK3210.RAR - 32 bit Windows TDK CTL file editor. These programs can be bundled with any program you write with TDK. For more information, contact Brad Larned (brad@psnw.com) 1:205/65@FidoNet... Shutting Down Your Door: ──────────────────────── There is no need to call any special procedure to shut down The DoorKit at the end of your program. If you look at the _EXIT.PAS unit, you will notice that there is automatic error handling in this kit. Even if your door exits with a runtime error, all of the required exit processes will be taken care of for you. You can add steps to the exit process with AddToExitChain. Just read the comments in the _EXIT.PAS unit and you'll see how simplified the exit or shutdown process is. What's more is if your program bails out with a runtime error, a detailed description of the error is written to an error log file. Believe me, this _EXIT.PAS is a lifesaver of a unit! Writing InterBBS Compatible Doors: ────────────────────────────────── TDK has no built in capabilities for writing InterBBS compatible doors due to the fact that there is no standard for this kind of thing. There is no way for me to know what type of data you need to share between BBSes, so I simply can't put anything in TDK to support that. However, writing InterBBS doors really involves nothing more that adding the capability to write Fido style *.MSG files with other files attached to them and being able to scan for new inbound *.MSG files with files attached to them. It has always been up to the program author to write the routines to unpack the archives, then import/export the door data to other systems. So, technically, all you need is the capability to read and write the *.MSG files. Luckily, there is one set of units available for this type of thing. MKSM106, by Mark May is the most complete message base access kit available. This kit supports Squish, JAM, Hudson, EzyCom, and Fido *.MSG message base formats. You can find it on Mark May's BBS (937)237-7737, 1:110/290@FidoNet. You may also download or freq the file MKSM106.RAR from the USA MAX Graphics HQ-BBS. By combining TDK with MKSM106, you have everything you need to write InterBBS doors... Writing MAX Compatible Doors: ───────────────────────────── Writing a MAX compatible door is actually easy with TDK, what makes it even easier yet is The MAX Graphics GUI Kit. This is an add on kit to TDK that allows you to write a MAX door in full local SVGA mode. This kit requires at least a shareware copy of the FastGraph/Light graphics kit. Everything you need is available from the USA MAX Graphics HQ-BBS or the web site. The file name for The MAX Graphics GUI kit is MXGUI + MAXscript Version + .RAR, or MXGUI###.RAR where ### is the current MAXscript version number. You may jump to the FastGraph web site (www.fastgraph.com) from the MAX Graphics web site (http://home.att.net/~maxgfx) and pick up the most recent version of the FastGraph graphics development kit... The TDK Unit Descriptions: ────────────────────────── ASYNC.PAS - The UART communications unit. ANSIUNIT.PAS - The local ANSI display unit. CHECKPAT.PAS - Used by EXEC.PAS for checking the DOS path. COMM.PAS - The main communications handler unit. CRCUNIT.PAS - Used for calculating file and string CRC32 values. DIGIBORD.PAS - The DigiBoard communications unit. DOORKIT1.PAS - The main TDK unit, startup, shutdown and critical routines. DOORKIT2.PAS - The TDK string and file handling unit. DOORKIT3.PAS - The TDK ANSI output unit, TDK's ANSI display nerve center. EXEC.PAS - The child process & DOS shell unit. FOSUNIT.PAS - The fossil communications unit. GENOVR.PAS - The automatic overlay generator unit. OVERXMS.PAS - Allows overlays to load into XMS rather than EMS memory. MAX_UNIT.PAS - Processes and sends MAXscript/MAXcontrol/MAXcolor commands. TDK_VARS.PAS - All of TDK's global variables and time slicing. _EXIT.PAS - The runtime error trapping and auto shutdown unit. ─────────────────────────────────────────────────────────────────────────────── Nine Ways To Hack/Crack Protect Your Doors: ─────────────────────────────────────────── Unless you are like me (primarily a freeware author) you are faced with the constant threat of someone cracking your door or hacking out copies of it. Granted that there is no fool proof method of preventing this, however, you can take measures to lessen the likelihood of this happening. Below are a few tips to help you secure your programs: 1. Don't release a shareware program that is capable of being thrown into full registered mode by entering a code or dropping a key file into the program directory. Registration codes can be figured out quite easily, and most key files are easily cracked as well. The best way to prevent this is to release your shareware programs without the full registered features compiled into it. Make your registered versions require a new executable with the registered user's name compiled into it. When ever you get a registration, then send the user a registered status program executable instead of a key file or registration code. It's no harder to do this than it is to send them a key file or registration code... 2. Don't ever put procedures or information in an overlay file that could be altered in order to make your program appear to be registered. These are probably the easiest file for a cracker to modify. Overlays cannot be encrypted like executables unless someone has invented some new and improved overlay manager that I'm not aware of. Critical procedures and information that control your program's security should always be kept in the executable, and the executable should always be encrypted... 3. Don't ever rely on CRC values of anything as registration codes! This is the first thing that a cracker will try when attempting to figure out a registration code. Yes, to the average user, CRC values of names look like a very reliable way of generating registration codes because they aren't visually readble or decipherable. But a cracker or another programmer will look at this as a kindergarten toy, and will have your registration codes figured out in about a minute or less. The only time you should use CRC values is for things that don't control the overall program security... 4. Don't ever rely on PKLITE or other similar executable compressors for securing an executable. Numerous programs out there can decompress a compressed executable. The UNP.EXE utility is a very popular tool for crackers because it can decompress any compressed executable. Yes, it will even decompress a so called "Permanently Compressed" PKLITE'ed executable. If you want to secure an executable, you will be further ahead to use an executable encryption program. The very best one you can get is called "Protect!" from Jeremy Lilley. This utility can be found on most any shareware CD-ROM, or you can reach the author at the addresses listed below: Jeremy Lilley Protect! EXE/COM 2711 Oak View Circle Medford, Oregon 97504 Email: jjlilley@mit.edu * CompuServe: 75060,2074 URL: http://web.mit.edu/jjlilley/www/protect.html 5. If you do insist on using key files to register your program, it's best to use a key generation unit where the author is the only person that has the source code to it. Think about it, if you use something where anybody that registers the key generator gets the source code, then any cracker out there will be able to figure out how to crack the keys made by your generator. You should _only_ use a key generator where all you get is the .TPU file itself. The absolute best key generation unit for Pascal is called "KeyCode" by Bob Westcott. Bob is the only one with the source code and his keys are going on a 10 year record of NEVER being cracked. You can reach Bob Westcott at: Bob Westcott Rt #1 Box 231A Macomb, OK 74852 Voice 405-333-2252 Data(BBS) 405-333-2424 FAX 405-333-2424 FidoNet 1:147/48 Internet westcott@telepath.com http://www.telepath.com/westcott 6. Don't ever base your registered status on whether or not a program just displays a text string that says "Registered" or "Unregistered". This can easily be changed by loading the executable into a hex editor and typing over the word "Unregistered". If your program is actually fully functional with the exception of the text string it displays, you can hide the string so that it doesn't appear in a hex editor, thus making the little crackers out there very frustrated. Use this technique, you may also use this technique to hide the registered user's name in the executable as well: {000000000111111111122222222} CONST {123456789012345678901234567} Alpha1 : STRING[27] = 'ABCDEFGHIJKLMNOPQRSTUVWXYZ.'; Alpha2 : STRING[27] = 'abcdefghijklmnopqrstuvwxyz!'; VAR Unregistered : STRING[13]; Registered : STRING[10]; PROCEDURE SetRegStrings; BEGIN Registered := COPY(Alpha1,18,1) + COPY(Alpha2,5,1) + COPY(Alpha2,7,1) + COPY(Alpha2,9,1) + COPY(Alpha2,19,1) + COPY(Alpha2,20,1) + COPY(Alpha2,5,1) + COPY(Alpha2,18,1) + COPY(Alpha2,5,1) + COPY(Alpha2,4,1); Unregistered := COPY(Alpha1,21,1) + COPY(Alpha1,14,1) + COPY(Alpha1,18,1) + COPY(Alpha1,5,1) + COPY(Alpha1,7,1) + COPY(Alpha1,9,1) + COPY(Alpha1,19,1) + COPY(Alpha1,20,1) + COPY(Alpha1,5,1) + COPY(Alpha1,18,1) + COPY(Alpha1,5,1) + COPY(Alpha1,4,1) + COPY(Alpha2,27,1); END; Using the above technique allows you to display the words "Registered" and "Unregistered" in your programs, but if the executable is loaded in a hex editor, the strings of text never show. You can copy letters from the two alpha strings to create any string of text you want, and the string will be basically invisible to peering eyes... 7. If you use the above method to hide the person's name and BBS name in your executables, you should always compare this information against the sysop name or BBS name in the drop file. Keep in mind that certain drop files contain information that other drop files don't. So you'll want to design your programs to adjust to the drop file. Chances are a person won't change the name of their BBS or the sysop name in the BBS just so they can run a hacked copy of your program... 8. This is the one that I've gotten the most ridicule for suggesting, but it works. Though it's not fool proof, it does ruin the fun for people that like to give registered copies of your programs out to others. If it's good for the big commercial companies, then I figure it's just as good for shareware authors. If you use custom compiled executables as part of your registration method, besides hiding the registered user's name in the executable, require the registered user to also give you the volume ID and serial number of the hard drive the program will be installed on and make your program dependent on that. As I said, this isn't fool proof because you can easily change your hard drive label and serial number with some low level programming. But, this can HELP prevent people from handing out registered copies to other people... 9. Executable compression can be used to HELP prevent tampering, though it takes some tap dancing to make it work. One technique that some people use is to compile the program, PKLITE the executable, and then note the size of the executable. Say that the compressed executable is 100,000 bytes. You put a routine in your program startup to check the file size and if the file size isn't exactly 100,000 bytes, then have your program halt. Always use PARAMSTR(0) as the file name when checking in case the executable was renamed by the user in an attempt to get around this. As I said, it takes some tap dancing because sometimes the executable may compress differently each time. So rather than use an exact figure, you may want to make the upper limit of the file size a little larger. Like, instead of checking to see if it's 100,000 bytes, tell your program that if the executable is greater than 100,020 bytes, then the executable has been altered and the program should shut down... ─────────────────────────────────────────────────────────────────────────────── Enforcing Program Test Drive Periods: ───────────────────────────────────── As you probably well know, it doesn't matter one way or the other to most sysops if doors on their system say they are registered or not. I've seen some sysops run doors for up to three years without registering them, when the program documentation clearly explains the 30 day test drive period... Believe it or not, you actually can enforce this 30 day limit and it won't make any difference if the sysop back dates their system or not. What I've done is just look for directories on the person's hard drive that you can hide files in. Great things to look for are C:\DOS, C:\WINDOWS, C:\OS2, or any other directory of your choice. It's best to use more than one file to keep track of dates and days run. If you look at the structure of the .CTL files, you'll see that there are date fields in there. What you will want to use is the .CTL file as well as two other files stored in other places on the hard drive using inconspicuous file names. Every time the door runs you will want to check the system date, then check the dates stored in all three files. If the dates don't match, then increment your day counter... The reason for the use of three different files is because there is always the chance one of these files may get deleted. If this happens, you still have two more files that you can check, and then just rewrite the deleted file again. Be sure that all three files are stored in different places as well. This way if the sysop tries to delete the program and re-install it in order to get around the 30 day trial, you still have the other backup files on the hard drive that you can read the counters/dates out of. When your counter hits 30 days (or whatever limit), you force your door to exit with an expiration message...Wella'...Your door now enforces your program test drive period... ─────────────────────────────────────────────────────────────────────────────── ANSI ESCAPE SEQUENCES ─────────────────────────────────────────────────────────────────────────────── Wherever you see '#', that should be replaced by the appropriate number. ESC code sequence Function ------------------- --------------------------- Cursor Controls: ESC[#;#H or ESC[#;#f Moves cusor to line #, column # ESC[#A Moves cursor up # lines ESC[#B Moves cursor down # lines ESC[#C Moves cursor forward # spaces ESC[#D Moves cursor back # spaces ESC[#;#R Reports current cursor line & column ESC[s Saves cursor position for recall later ESC[u Return to saved cursor position Erase Functions: ESC[2J Clear screen and home cursor ESC[K Clear to end of line Set Graphics Rendition: ESC[#;#;....;#m Set display attributes where # is 0 for normal display 1 for bold on 4 underline (mono only) 5 blink on 7 reverse video on 8 nondisplayed (invisible) 30 black foreground 31 red foreground 32 green foreground 33 yellow foreground 34 blue foreground 35 magenta foreground 36 cyan foreground 37 white foreground 40 black background 41 red background 42 green background 43 yellow background 44 blue background 45 magenta background 46 cyan background 47 white background ESC[=#;7h or Put screen in indicated mode where # is ESC[=h or 0 for 40 x 25 black & white ESC[=0h or 1 for 40 x 25 color ESC[?7h 2 for 80 x 25 b&w 3 for 80 x 25 color 4 for 320 x 200 color graphics 5 for 320 x 200 b & w graphics 6 for 640 x 200 b & w graphics 7 to wrap at end of line ESC[=#;7l or ESC[=l or Resets mode # set with above command ESC[=0l or ESC[?7l Keyboard Reassignments: ESC[#;#;...p Keyboard reassignment. The first ASCII or ESC["string"p code defines which code is to be or ESC[#;"string";#; changed. The remaining codes define #;"string";#p what it is to be changed to. E.g. Reassign the Q and q keys to the A and a keys (and vice versa). ESC [65;81p A becomes Q ESC [97;113p a becomes q ESC [81;65p Q becomes A ESC [113;97p q becomes a E.g. Reassign the F10 key to a DIR command. ESC [0;68;"dir";13p The 0;68 is the extended ASCII code for the F10 key and 13 is the ASCII code for a carriage return. Other function key codes F1=59,F2=60,F3=61,F4=62,F5=63 F6=64,F7=65,F8=66,F9=67,F10=68 ─────────────────────────────────────────────────────────────────────────────── DROP FILE FORMATS ─────────────────────────────────────────────────────────────────────────────── Filename: DORINFO1.DEF Description: A standard exit file created in the current (node) directory. This is a standard ASCII text file used by many external programs. This is a very limited exit file, but this just so happens to be a standard amongst a large number of BBS packages. Line 1: System name Line 2: Sysop first name Line 3: Sysop last name Line 4: Communications port in use (COM0 if local) Line 5: Communications port settings: BPS rate,parity,data bits,stop bits The BPS rate is specified as 0 during local sessions and is followed by the word BAUD. During error- free connects, the word BAUD is followed by -R. The parity setting is always set to N for no parity. The data bits are always set to 8 and the stop bits are always set to 1. Line 6: Reserved (always zero) Line 7: User first name Line 8: User last name Line 9: User location Line 10: User emulation (0=ASCII, 1=ANSI, 2=AVATAR) Line 11: User security level Line 12: User time remaining (in minutes) ─────────────────────────────────────────────────────────────────────────────── Filename: DOOR.SYS Description: A standard exit file created in the current (node) directory. This is a standard ASCII text file used by many external programs. Although this exit file is extremely detailed and includes information that cannot be generated by every BBS type, efforts were made to include as much information as possible. Line 1: Communications port (COM0: if local) Line 2: BPS rate Line 3: Data bits Line 4: Node number Line 5: DTE rate (locked rate) Line 6: Screen display (snoop) (Y=On N=Off) Line 7: Printer toggle (Y=On N=Off) Line 8: Page bell (Y=On N=Off) Line 9: Caller alarm (Y=On N=Off) Line 10: User full name Line 11: User location Line 12: Home/voice telephone number Line 13: Work/data telephone number Line 14: Password Line 15: Security level Line 16: User's total number of calls to the system Line 17: User's last call date Line 18: Seconds remaining this call Line 19: Minutes remaining this call Line 20: Graphics mode (GR=ANSI, NG=ASCII) Line 21: Screen length Line 22: User mode (always set to N) Line 23: Always blank Line 24: Always blank Line 25: Subscription expiration date Line 26: User's record number Line 27: Default protocol Line 28: User's total number of uploads Line 29: User's total number of downloads Line 30: User's daily download kilobytes total Line 31: Daily download kilobyte limit { Short DOOR.SYS stops at line #31 } Line 32: User's date of birth Line 33: Path to the user database files Line 34: Path to the message database files Line 35: Sysop full name Line 36: User's handle (alias) Line 37: Next event starting time Line 38: Error-free connection (Y=Yes N=No) Line 39: Always set to N Line 40: Always set to Y Line 41: Default text color Line 42: Always set to 0 Line 43: Last new files scan date Line 44: Time of this call Line 45: Time of last call Line 46: Always set to 32768 Line 47: Number of files downloaded today Line 48: Total kilobytes uploaded Line 49: Total kilobytes downloaded Line 50: Comment stored in user record Line 51: Always set to 0 Line 52: Total number of messages posted ─────────────────────────────────────────────────────────────────────────────── Entry Form Script Files: ──────────────────────── This is a basic list of instructions for TDK scripts to follow which tell it what screen file to display, what to write on the screen, what type and length of entry fields to place on the screen, what text file to write the entry field data to, etc. The array of commands is small, but there are a lot of possibilities for their use. A total of 50 entry fields per script are allowed which should be plenty to gather all the information you need. The script files are read from top to bottom and all information entered in the script is displayed exactly in that order. Global System Variables are allowed throughout the entire script file as well. Also, the script commands are not case sensitive to make them easier to use. All commands must be on a line by themselves, you cannot have more than one command on each line. For an example of an Entry Form Script File, take a look at the file QUEST1.FRM...Refer to DOORKIT3.PAS / RunEntryForm for more details... Script Commands And Format: ─────────────────────────── ScreenFile@ - This is the name of a screen file that you would like to display. Screen files can be displayed at any time in the script. Do not include a file extension on the screen file name since this will be determined by the user's graphics capabilities. However, you must include the full path to the screen file. ShowTextFile@ - This command displays a text file of your choice. All you do is this: ShowTextFile@C:\DOOR\FEATURES.TXT and the text file will be displayed to the user until they select Quit. Cls@ - This simply clears the screen. TextFile@ - This is the name of the text file that you wish to output the data from all of your entry fields. This file should be declared at the beginning of your script. Only one text file is allowed per script file. LineFeed@ - This simply draws a blank line on the screen. AnyKey@ - This prompts the user to press any key to continue. PromptText@ - This command precedes any text that you wish to display on the screen. To display a prompt to ask a user for his/her phone number you would simply add this line to your script: "PromptText@What Is Your Phone Number?" (Without the quotes) NormalPrompt@ - This is the first of the entry fields, each entry field has two parameters separated by an "@" code. The first parameter is the length of the field (1 To 255). The second is the default data to "Stuff" into the field. The normal prompt accepts your input exactly as you type it, no capitalization or correction is performed. If you wanted to get the user's main BBS interests in a field that is 30 characters wide and stuff it with some default data, you would do this: NormalPrompt@30@Your Main BBS Interests Are The result is this: [Your Main BBS Interests Are___] If you want a blank field 30 characters wide, do this: NormalPrompt@30 The result is this: [______________________________] NumberPrompt@ - This performs the same way as the above, except that this field only allows numeric characters as input. ProperPrompt@ - The same rules apply here as well except that this field automatically capitalizes the first letter of each word. Use this for getting names or city, state, street names. HiddenPrompt@ - Again, the same rules apply with the exception that the user never sees their input. All they see are dots in the field whenever they enter a character. Use this for getting passwords, etc.... CapitalPrompt@ - Once again, the same rules apply with the exception that every character entered in this field is capitalized. You can use this for getting file names or country names, etc. OutText@ - This is used to output text and field data to the text file you declared with the TextFile@ command. This is another command with two parameters separated by an "@" code. The first parameter is any text that you want to write to the text file. Entering an OutText@ all by itself will simply write a blank line to the text file. If you want to write your BBS name to a line, do this: OutText@{BBS} If want to add a line of text and the data from the first entry field, do this: OutText@Main BBS Interests : @1 RunBatchFile@ - This is used in a script to run an external batch file. In some cases you may find a need to run an external door or have Max-Menu shell out and do some DOS file manipulation. The batch file doesn't have to execute a door, it can run any program. Some people may want to send a file to users with some kind of an external protocol driver. Your script file would simply show: RunBatFile@C:\DOOR\FILENAME.BAT or whatever the batch file name happens to be. You may also pass parameters to your batch file as well through the use of Global System Variables or your own parameters. ─────────────────────────────────────────────────────────────────────────────── Credits: ──────── Larry L. Athey - The structure of TDK, numerous complex procedures, numerous "Artsy/Fartsy" procedures, and the concept & design of MAX Graphics itself. Brad Larned - Special thanks to Brad Larned of The Fresno Online BBS (209)276-3657 (owner of FzSoft Software) for releasing the very first door (outside of my own) written using TDK!!! Also, for doing virtually all of the debugging of the first version of TDK as well as releasing the very first MAX compatible SVGA door. Brad is also the author of the Windows TDK CTL file editors. Sean Price - Special thanks to Sean Price of Rude Dog Software for fixing a problem that has been a burden since the beginning of MAX Graphics. The proper color averaging of PCX images is now fixed thanks to Sean. Sean as well as Brad Larned were the very first MAXecutable program creators, for more information on Rude Dog Software, contact the Sanctuary From The Law BBS (619)377-3611. Jon Parise - Special thanks to Jon Parise of ntsSoft for numerous suggestions, enhancements and ideas. Who says you've got to be old to be wise? This guy's young, but he's probably got a better grasp on BBS/Door development than people twice his age. You can reach Jon Parise at 1:2606/421@FidoNet, jon@interpow.net, or you can also reach his BBS at (908)637-8243. Dorinda D Hayek - Major contribution to the MAX Graphics development kit and made a number of changes in TDK v1.10 to optimize performance and enhance features. Her contribution to TDK v1.10 made the quick release of v1.20 possible. SWAG Support - The SourceWare Archival Group. A HUGE amount of code in this kit came from SWAG. Since there are too many people to name, I will simply pay credit to "SWAG" here. Thomas Wagner - The EXEC.PAS unit and supporting files. This is a great unit specifically designed to replace the EXEC command in Pascal. The unit has built in memory swapping and when you execute a child process or drop to DOS, only a 1.2K foot print is left in memory thus giving the most free memory to run external programs. Anybody Else? - If there is a chance that I'm using code in this kit from anybody I neglected to mention, sorry about that. Let me know and tell me what portion of the code it is that you are the author of and I'll add your name to the list. ─────────────────────────────────────────────────────────────────────────────── ┌───────────────────────────────────────────────────────────────────┐ │ │ │ ┌── ┌────── ┌────── ┌────── ┌────── ┌──────── │ │ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │ │ ┌── ┌──────── ┌──── ┌────── ┌── ┌── ┌──── ┌── │ │ ┌── ┌── ┌── ┌── ┌── ┌── ┌── ┌── │ │ ┌────── ┌── ┌── ┌────── ┌────── ┌── ┌── │ │ │ └───────────────────────────────────────────────────────────────────┘ Not just software....It's a computer enhancement! ┌───────────────────────────────────────────────────────────────────┐ │ Contact: 1:14/703@FidoNet Or: USA MAX Graphics HQ-BBS │ │ 411:1500/0@ivNET (308)762-2239 │ │ 121:101/2@AllianceNet FAX or Data Calls │ │ maxgfx@juno.com ANSI/ASCII/MAX (No RIP) │ └───────────────────────────────────────────────────────────────────┘ ───────────────────────────────────────────────────────────────────────────────